What about the case where the EOA goes above the same limit, shouldn't the tx be rejected in that case? Do we already have that in place?

What about the case where the EOA goes above the same limit, shouldn't the tx be rejected in that case? Do we already have that in place?

Yes it should, tx_pool doesn't have such check, but nonces are already uint64 there. Digging deeper to find where it's decoded...

Here I found another place where the check is missing when external transaction updates the sender's nonce.

cc @axic

And creation transaction BTW goes through the same code path as CREATE/CREATE2 and with this PR should already result in failed execution

EIP is not very clear for this case, (it only mentions tx nonce being above 64 bit, which is already rejected by geth as invalid tx encoding) I think it would make sense for a transaction to be valid and fail.

The mempool is not part of the EIP as clients are free to decide how they select transactions.

EIP is not very clear for this case, (it only mentions tx nonce being above 64 bit, which is already rejected by geth as invalid tx encoding) I think it would make sense for a transaction to be valid and fail.

The mempool is not part of the EIP as clients are free to decide how they select transactions.

"is not very clear" did not refer to the mempool, but to external transaction updating sender's nonce when included.

EIP is not very clear for this case, (it only mentions tx nonce being above 64 bit, which is already rejected by geth as invalid tx encoding) I think it would make sense for a transaction to be valid and fail.

The mempool is not part of the EIP as clients are free to decide how they select transactions.

"is not very clear" did not refer to the mempool, but to external transaction updating sender's nonce when included.

Such transactions should not be accepted, i.e. they are invalid.

"is not very clear" did not refer to the mempool, but to external transaction updating sender's nonce when included.

Such transactions should not be accepted, i.e. they are invalid.

This would make transactions with nonce == 0xffffffffffffffff invalid (and not only where the nonce exceeds 2^64-1 as EIP states)

This would make transactions with nonce == 0xffffffffffffffff invalid (and not only where the nonce exceeds 2^64-1 as EIP states)

I mean those which exceed are invalid.

This would make transactions with nonce == 0xffffffffffffffff invalid (and not only where the nonce exceeds 2^64-1 as EIP states)

I'd agree with that: by themselves they are valid, but since nonce increase is a consequence of including them, they lead to breaking the rule. Hence they must be rejected and cannot be included in a block. (not in the txpool though, this is a consensus rule)

Hmm, that's an interesting point, that the increase is part of the inclusion, so transaction nonce 2^64-1 can't be included. We should perhaps clarify this in the EIP.

Triage discussion: we should fix both nonce-out-of-bounds cases in the same PR

I think a change to evm transaction tool is also needed.

Hmpf...

ERROR: Permission to ewasm/go-ethereum.git denied to holiman.

Please cherry-pick from https://github.com/holiman/go-ethereum/commits/deletelater